C#でクラウドアプリを作る場合、 Azure Functions(サーバーレス) と ASP.NET Core Web API(常駐API) が定番です。 バッチ・Webhook・軽量APIは Functions、 本格的なREST APIは Web API が向いています。
この記事でわかること
・Azure Functions(HTTPトリガー)の基本
・ASP.NET Core Web API の基本構成
・DI・設定・ローカル開発
・認証(APIキー / Bearer)
・Functions と Web API の使い分け
・業務アプリ向けクラウド構成の考え方
・Azure Functions(HTTPトリガー)の基本
・ASP.NET Core Web API の基本構成
・DI・設定・ローカル開発
・認証(APIキー / Bearer)
・Functions と Web API の使い分け
・業務アプリ向けクラウド構成の考え方
1. Azure Functions と Web API の違い
| 項目 | Azure Functions | ASP.NET Core Web API |
|---|---|---|
| 特徴 | サーバーレス・イベント駆動 | 常駐API・フルフレームワーク |
| 課金 | 実行時間・回数ベース | 常時稼働(App Service等) |
| 向き | バッチ・Webhook・軽量API | 本格REST API・大規模システム |
| スケール | 自動スケール◎ | スケール設定が必要 |
軽量・イベント駆動 → Functions API中心・長期運用 → Web API
2. Azure Functions(HTTPトリガー)の基本
■ 2-1. 最小のHTTPトリガー関数
using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
public class HelloFunction
{
private readonly ILogger _logger;
public HelloFunction(ILoggerFactory loggerFactory)
{
_logger = loggerFactory.CreateLogger<HelloFunction>();
}
[Function("Hello")]
public HttpResponseData Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
{
_logger.LogInformation("Hello function triggered.");
var response = req.CreateResponse(HttpStatusCode.OK);
response.WriteString("Hello from Azure Functions!");
return response;
}
}
URL例:
https://<app-name>.azurewebsites.net/api/Hello?code=...(Functionキー)
■ 2-2. JSONレスポンス
public record HelloResponse(string Message, DateTime Timestamp);
[Function("HelloJson")]
public HttpResponseData RunJson(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
{
var res = req.CreateResponse(HttpStatusCode.OK);
var body = new HelloResponse("Hello", DateTime.UtcNow);
res.WriteAsJsonAsync(body).Wait();
return res;
}
3. Azure Functions の設定・DI
■ 3-1. Program.cs(.NET Isolated)
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Configuration;
using Serilog;
var host = new HostBuilder()
.ConfigureFunctionsWorkerDefaults()
.ConfigureAppConfiguration((ctx, cfg) =>
{
cfg.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
})
.ConfigureServices((ctx, services) =>
{
services.AddSingleton<IMyService, MyService>();
})
.UseSerilog((ctx, cfg) =>
{
cfg.WriteTo.Console();
})
.Build();
host.Run();
通常の .NET アプリと同じ感覚で DI・設定を使えます。
4. ASP.NET Core Web API の基本
■ 4-1. 最小のWeb API(Minimal API)
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/hello", () => new { Message = "Hello Web API", Time = DateTime.UtcNow });
app.Run();
■ 4-2. コントローラベースのAPI
[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
[HttpGet("{id}")]
public ActionResult<UserDto> Get(int id)
{
return new UserDto(id, "Taro");
}
}
public record UserDto(int Id, string Name);
5. 認証・認可の基本(APIキー / Bearer)
■ 5-1. Azure Functions の AuthorizationLevel
- Anonymous:誰でも呼べる
- Function:関数キーが必要
- Admin:管理キーが必要
外部公開APIなら、APIMやFront Doorと組み合わせてBearer認証を載せるのが定番です。
■ 5-2. Web API + Bearerトークン(概念)
builder.Services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.Authority = "https://login.microsoftonline.com/...";
options.Audience = "api://your-api-id";
});
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/secure", [Authorize] () => "Secure");
Azure AD / Entra ID と組み合わせると、企業向けAPIとして運用しやすくなります。
6. ローカル開発とデプロイの流れ
■ 6-1. Azure Functions
- Azure Functions プロジェクトを作成
- Azure Functions Core Tools でローカル実行
- Storage Emulator or Azurite を利用
- VS / CLI から Azure に発行
■ 6-2. Web API
- ASP.NET Core Web API プロジェクトを作成
- Swagger でローカル確認
- App Service / Container Apps にデプロイ
どちらも「ローカルで動かしてからクラウドへ」が基本です。
7. Functions と Web API の使い分けパターン
- バッチ処理・タイマー・キュー連携 → Functions(Timer / Queue トリガー)
- Webhook受信・軽量API → Functions(HTTPトリガー)
- 業務システムの中核REST API → Web API
- フロントエンドSPAのバックエンド → Web API + Functions(補助)
「APIの入口はWeb API、裏側のバッチはFunctions」という構成もよくあります。
8. 業務アプリ向けベストプラクティス
- 軽量・イベント駆動 → Azure Functions
- 本格REST → ASP.NET Core Web API
- どちらも DI・設定・ログをきちんと設計する
- 認証は Azure AD / APIM と組み合わせて考える
- ローカルで再現できる構成にしておく(開発効率UP)
- ログ・メトリクス(Application Insights)を必ず有効化
まとめ:C# × Azure Functions / Web API で“クラウド常識”を一気に押さえる
- Functions → サーバーレスで小さく早く
- Web API → 中核APIをしっかり設計
- 両者を組み合わせると、業務クラウドアプリの選択肢が一気に広がる
「まずは小さくクラウドに出したい」「将来拡張できるAPI基盤が欲しい」 というニーズに対して、 C# × Azure Functions / Web API は非常に相性の良い組み合わせです。 この記事をベースに、あなたのプロジェクトに合ったクラウド構成を設計してみてください。